DNSSEC is a suite of Internet Engineering Task Force (IETF) specifications for securing certain kinds of information provided by the DNS as used on Internet Protocol (IP) networks. It is a set of extensions to DNS, which provide to DNS users origin authentication of DNS data, authenticated denial of existence, and data integrity. All answers in DNSSEC are digitally signed. By checking the digital signature, a DNS user is able to check if the information is identical (correct and complete) to the information published at the authoritative DNS server.
DNSSEC was standardized in 2005 and uses a straightforward hierarchical verification architecture to learn keys and verify data. DNSSEC has become one component of naming and resolution services provided by DNS registry services. However, it has become apparent that DNSSEC's verification model does not adequately support the flexibility and robustness needed by Internet systems. DNSSEC's design verifies DNS data when deployment operates without benign misconfigurations. This is in contrast to DNS, which offers robustness to many types of misconfigurations. In a sense, DNSSEC presumes near-perfect operational deployments.
By way of a simplified example of a top-level domain (TLD) implementing DNSSEC, the DNS records in the TLD zone file are digitally signed using a private key. The corresponding public key is published as a DNSKEY record in the TLD zone file, and is given to the root name server's provisioning system, which digitally signs a DNS record containing the fingerprint of the public key (a Delegation Signer (“DS”) record) with the root zone's private key. The root zone's public key may be retrieved directly by a relying party from a local trust list by a client application. A lookup request queries the trusted root zone for authoritative name server information for the TLD and for the associated public key fingerprint. The public key fingerprint is then used to verify the TLD's public key. This process keeps the chain of trust intact. Because a lookup request begins with a trusted node (the root server), each subsequent step in the chain of lookups maintains the trust by using the public/key private key infrastructure. Thus, once the TLD's public key is verified using the public key fingerprint from its “parent”, the root zone, the TLD name server returns the public key fingerprint for the next authoritative name server, which is digitally signed with the TLD's private key. The next authoritative name server has also digitally signed its DNS records with a private key. The chain continues indefinitely until the last node is reached and the ultimate DNS record, e.g., a record containing a web server's IP address, is determined. (Note that in practice, the DNSSEC trust chain typically is slightly more complex, with two levels of keys per zone. A key-signing key signs DNSKEY records, and a zone-signing key signs other records, including the DS record containing the fingerprint of the next zone's key-signing key.)
If a failure occurs during at any stage of the DNSSEC chain of trust verification process, the requestor typically has no other mechanism to validate the requested DNS record. The requestor may be provided the DNS record and may have to make a determination as to whether the record is trustworthy. Alternatively, the requestor may not be provided the DNS record. In either case, the results are not optimal for the requestor. Thus, there is a need for a mechanism to validate DNS records when DNSSEC is not functioning properly, i.e., when DNSSEC is “imperfect.”